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DETAILED ACTION 

1 . The Office Action is responsive to the communication filed on 1 0/29/2009. 

2. Claims 1-2, 4-5, 8-13, 15-19, 21-26, 28-30, 32, 34-39, 41-42, and 44-49 are pending. 



Response to Amendment 

3 . The amendment, filed 1 0/29/2009, has been entered. 

Response to Arguments 

4. Applicant's arguments with respect to claims 1-2, 4-5, 8-13, 15-19, 21-26, 28-30, 32, 34- 
39, 41-42, and 44-49 have been considered but are moot in view of the new ground(s) of 
rejection. 

A] Claim Interpretation 

During patent examination, the claims are given the broadest reasonable interpretation 
consistent with the specification. See In re Morris, 127 F.3d 1048, 44 USPQ2d 1023 (Fed. Cir. 
1 997). See MPEP § 2 1 1 1 - § 2 1 1 6.0 1 for case law pertinent to claim analysis. 

Applicant's specification, paragraphs [0051], [0052], [0064], [0066], [0067], [0071], and 
[0096] enumerate the functionality of the normalization module. As understood, the 
normalization module functions to facilitate the querying and configuring of devices. In 
particular, the function is articulated as 1) providing network driver capabilities/status and 2) 
specifying, by the rules engine, configuration commands to the media specific drivers. The 
structure of the module may exist as an application layer and/or be incorporated into either the 
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rules engine or the media specific module. In support, the specification, paragraph [0051], 

elaborates the function and structure of the normalization module. 

[ 0051] The media specific modules 320 are associated with two interfaces. The media specific 
modules 320 communicate with the rules engine via a generalized interface incorporated into a media specific 
normalization module 322. The normalization module 322, a layer that sits between the rules engine 300 and the 
media specific modules 320, facilitates standardizing communications between the rules engine 300 and media 
specific modules 320 of many types. The normalization module 322 facilitates: providing network driver 
capabilities/status information from the media specific modules 320 to the rules engine 300, and (2) specifying, by 
the rules engine 300, network interface configuration commands to the media specific drivers 302 via the media 
specific modules 320. Furthermore, the user-mode media specific modules 320 communicate with the media 
specific drivers 302, for example, according to (kernel mode) network driver interface specification (NDIS) 340. 
While the illustrative embodiment provides a media specific module for a particular medium type or class of media 
types, it is contemplated that alternative embodiments of the invention include composite media specific modules 
that support multiple, unrelated media types (e.g., a WWANAVLAN media specific module). Furthermore, while the 
normalization module 322 is shown as a separate entity from both the rules engine 300 and the media specific 
modules 320, in alternative embodiments of the invention the functionality of the normalization module is 
incorporated into either the rules engine 300 or the media specific modules 320. 



The normalization module is interpreted as providing at least two functions of facilitating 
both status retrieval and configuring respective interface card (e.g., The normalization module3 22 
facilitates: providing network driver capabilities/status information from the media specific modules 320 to the rules 
engine 300, and (2) specifying, by the rules engine 300, network interface configuration commands to the media 
specific drivers 302 via the media specific modules 320) Although Melpignano et al. teaches these 
functions in separate code (IfPriority and IfStatus), the code may nevertheless be integrated into 
a single module. Furthermore, this module may be incorporated as part of the Network Interface 
Class either as a separate or integrated module (e.g., in alternative embodiments of the invention the 
functionality of the normalization module is incorporated into either the rules engine 300 or the media specific 
modules). 

As per MPEP Section 2144.04 [R-6] V. Making Portable, Integral, Separable, Adjustable, or 
Continuous, the functionality of two modules may be integrated into a single module. 
Melpignano et al. teaches a media specific module interface incorporating separate modules or 
code for facilitating the function of 1) providing status information (IfStatusFlags) and 2) 
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configuration commands (IfPriority) ([0050] e.g., a priority can be dynamically changed by the 
IfManager, i.e., rules engine, much in the same way that the normalization module functions to 
provide configuration commands to the network interfaces. These modules may be integrated 
into a unified module where this module performs a substantially similar functionality of 
facilitating both status information and configuring a network interface. 

As applied to applicant's amendment, this module converts standardized communication 
requests it receives from the rules engine into media specific communications that meet media 
specific implementation requirements (e.g., IfPriority is a function of setting the priority per 
network interface card. It is media specific because the priority is set per card. Media specific 
implementation requirements correspond to setting a priority for an interface based on at least 
user specification, card capabilities, etc. Second, IfStatus functions to retrieve the status per 
interface card that is best understood as directing media specific communications (e.g., status 
request) to respective network interfaces. 

In effect, an integrated module provides the function of 1 ] configuring a priority of an 
interface using an IfManager, i.e., rules engine (e.g., converts standardized communication 
requests it receives from the rules engine into media specific communications that meet media 
specific implementation requirements) and 2] requesting status information per interface (e.g., 
configured to direct media specific communications to respective network interfaces) 

The above discussion is incorporated into the newly added claim limitations with regard to a 
normalization module. 
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Claim Rejections - 35 USC § 103 

5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

6. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 
(1966), that are applied for establishing a background for determining obviousness under 35 
U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness 
or nonobviousness. 

6. Claims 1-5, 8-14, 28-32, 34-40, and 45-47 rejected under 35 U.S.C. 103(a) as being 
unpatentable over Melpignano et al. (USPN 2006/0084417 Al) in further view of Shi (USPN 
6807163), 

7. As per claim 1, Melpignano et al. teaches a computing system supporting network 
selection based upon network information spanning multiple communication media, the system 
comprising: 

a rules data store ([0049], [FIG 3 - network interface 'if class diagrams] e.g., rules data store 
is interpreted as maintaining selection criteria) for maintaining network selection criteria ([0049- 
52], [0035] e.g., location, context class, Networklnterface class (priorities), user preferences, 
speed, power consumption, mobility profiles, cached information, security, and connection costs) 
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acquired from a plurality of sources ([0039], [0049 - suitable main classes of NISP], [FIG 3 - 
elements 200, 202, 210, 214] e.g., plurality of sources, not defined, may comprise multiple 
sources including user preferences, predefined sets or personal policies, and/or classes 
(AccessPoint, Networklnterface, and Context) where each class represents a source of network 
information pertinent to selecting an appropriate interface); 

a media specific module interface ([0050] e.g., Networklnterface class. It is interpreted that 
this class represents multiple interface types, such as Bluetooth, GPRS, WLAN (e.g., iftype, 
ifName, ifStatus) for providing accumulated network interface information ([Figure 3], [0050 - 
element 202] e.g., accumulate network interface information encompasses type, name, flags, 
physical characteristics per interface) potentially spanning multiple communication media ( e.g., 
Bluetooth, Wlan, GPRS, etc) , the accumulated network interface information being associated 
with a set of networks (e.g., WLAN, WPAN, etc) and a set of network interfaces ([0033 lines 3- 
4], [Figure 3-ifType] e.g., interface cards), each network interface for connecting the computing 
system to a network in the set of networks (e.g., connectivity to server via network); 

a rules engine ([0049-IfManager] e.g., the Nic Agent role is implemented by the IfManager 
class) for designating one of the set of networks by applying a network selection criterion from 
the rules data store to the accumulated network interface information potentially spanning 
multiple media ([0053-55] e.g., IfManager takes care of interface connectivity, management, and 
selection being performed by choosing the best interface according to context and user 
preferences. Since the IfManager accesses context, i.e., Context class, the rules engine in effect 
utilizes one or more classes to select the optimal interface) 
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wherein the media specific module interface ([Figure 3-element 202]) comprises a 
normalization module (e.g., supra 'response to arguments) that converts standardized 
communication requests it receives from the rules engine into media specific communications 
that meet media specific implementation requirements ([0050] e.g., IfPriority can be dynamically 
changed by the IfManager, i.e., communication requests it receives from the rules engine) , the 
normalization module further configured to direct the media specific communications to 
respective network interfaces ([0050] e.g., ifStatusFlags) 

Therefore, at the time the invention was made, one of ordinary skill in the art would 
recognize that the functions of providing configuring a network interface via a rules engine and 
requesting status information may be facilitated by separate modules and/or an integrated 
module. As per MPEP Section 2144.04 [R-6] V. Making Portable, Integral, Separable, 
Adjustable, or Continuous, the functionality of two modules may be integrated into a single 
module. Melpignano et al. teaches a media specific module interface incorporating separate 
modules or code for facilitating the function of 1) providing status information (IfStatusFlags) 
and 2) configuration commands (IfPriority) ([0050] e.g., a priority can be dynamically changed 
by the IfManager, i.e., rules engine, much in the same way that the normalization module 
functions to provide configuration commands to the network interfaces. In effect, a skilled 
artisan would have motivation to create an integrated module that serves that same function as 
two separate modules. 

Melpignano et al. teaches a scanning engine -([Figure 3-element 200 (ImScanning Type) 
associated with a network interface ([0055-56]) for adaptively controlling a scanning delay 
period ([0057] e.g., scanning at periodic intervals.), but does not disclose scanning based at least 
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upon results of a previous scan. Shi teaches an adaptive rate channel scanning method for 
adaptively changing the scan rate based on data stored in a channel table during previous 
channels scanned by the channel scan process ([COL 4 lines 30-41) ) (Note: Shi is also 
introduced to address applicant's specification regarding the scan rate and adapting) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to adaptively change the scan rate based on previous scan results to adapt to changing 
network conditions as a means to save battery power. Melpignano et al. teaches scanning for 
available access points at periodic intervals. Shi teaches changing the scanning rate based on 
previous scan results to conserve battery power. Since adaptively selecting a scan rate as a 
function of network conditions (as assessed via previous scan results) saves power, it would have 
been obvious to modify Melpignano et al. to adapt the scan rate based on previous scans. 

7. As per claim 2, Melpignano et al. teaches the computing system of claim 1 wherein the 
rules engine having has access to the rules data store ([FIG 3], [0054-56]) 

8. As per claim 4, Melpignano et al. teaches the computing system of claim 3 further 
comprising a plurality of media specific modules ([0033] , [0050] e.g., interfaces/associated 
device drivers corresponding to WLAN, WPAN, Bluetooth, IEEE 802.1 lb, i.e., media specific 
interface modules. Page 15 line 7 of applicant's instant specification) configured to acquire 
network interface information ([0050] e.g., fStatus) pertaining to network interfaces associated 
with particular media types, and to receive network interface configuration commands (e.g., 
priority) , from the rules engine, to connect to one of the set of networks ([0053-56]) 

9. As per claim 5, Melpignano et al. teaches the computing system of claim 4 wherein the 
media specific modules acquire network interface information from media specific drivers 
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associated with particular network interfaces ([0049-50] e.g., it is understood that interface 
device drivers provide status, capability, and list of reachable access points of the interface card) 

10. As per claim 8, Melpignano et al. teaches the computing system of claim 1 wherein the 
network selection criterion specifies a preference order between at least two media based upon a 
network parameter associated with the media ([0050] e.g., fPriority) 

11. As per claim 9, Melpignano et al. teaches the computing system of claim 1 wherein the 
network selection criterion specifies a preference order between at least two media based upon a 
network type associated with the media ([0050] fType) 

12. As per claim 10, Melpignano et al. teaches the computing system of claim 1 wherein the 
network selection criterion specifies a preference order based upon a current location of the 
computing system ([0052-56] e.g., location is one criteria employed in selecting an interface) 

13. As per claim 1 1 Melpignano et al. teaches the computing system of claim 1 wherein the 
network selection criterion specifies a preference order between logical networks ([0050] 
fPriority) 

14. As per claim 12, Melpignano et al. teaches the computing system of claim 1 wherein the 
network selection criterion specifies a preference order based upon a network time of use 
parameter ([0051] e.g., 'already been visited') 

15. As per claim 13, Melpignano et al. teaches the computing system of claim 1 wherein the 
rules engine is incorporated into a state machine that cyclically scans a set of network interfaces 
for networks ([0056-57], [FIG 4]), applies the network selection criterion to a set of networks 
and interfaces to render a current network and interface selection ([0053-57]), and issues 
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configuration instructions in accordance with the current network and interface selection ([0055- 
57]) 

16. As per claim 14, Melpignano et al. teaches the computing system of claim 1 further 
comprising a scanning engine associated with a network interface for controlling the timing of 
scanning based upon previous scan results maintained in a scanning history ([0057], [0061] e.g., 
scanning at periodic intervals. A list, i.e., scan history, of access points is maintained) 

17. As per claim 28, Melpignano et al. teaches a computer-readable medium including 
computer-executable instructions for facilitating selecting a network and interface combination, 
to which a computing system will initiate a connection via the network interface, based upon 
network information spanning multiple communication media, the computer-executable 
instructions facilitating: 

accessing network selection criteria acquired from a plurality of sources ([0039], [0049 - 
suitable main classes of NISP], [FIG 3 -elements 200, 202, 210, 214] e.g., plurality of sources, 
not defined, may comprise multiple sources including user preferences, predefined sets or 
personal policies, and/or classes (AccessPoint, Networklnterface, and Context) where each class 
represents a source of information pertinent to selecting an appropriate interface; 

accumulating network interface information ([0050 - element 202] e.g., plurality of interface 
cards and associated, class information) potentially spanning multiple communication media 
([0033] e.g., data, fax, video, or speech, Wlan, Bluethooth) associated with a set of networks 
(e.g., WLAN, WPAN) and a set of network interfaces ([0033 lines 3-4]), each network interface 
for connecting the computing system to a network in the set of networks (e.g., connectivity to 
server via network), 
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However, Melpignano et al. does not teach that the accumulating is facilitated by a 
normalization module that standardizes communication between a set of media specific modules 
and a rules engine. Nguyen teaches a network fault monitoring module ([0019], [0021], [0027] 
e.g., A normalization module, in light of applicant's specification, is interpreted as providing 
network status information. Applicant's specification teaches that the normalization module 
standardizes communication via providing status information from the media specific modules to 
the rules engine) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to provide a module to relay the status information from the Networklnterface class 
to the IfManager. Melpignano et al. teaches that the rules engine (e.g., IfManager) continuously 
monitors the network interface availability. Since multiple interfaces are provided, it is 
beneficial to accumulate and relay the status of each interface to the IfManager such that an 
appropriate interface may be selected. Since a network fault module, as taught by Nguyen, 
provides interface status information to other modules, it would have been obvious to include 
this module as part of the networkinterface class as part of the standard communication between 
the rules engine and network interface class;); and 

designating, via the rules engine ([0049], [0055]), one of the set of networks and a network 
interface from the set of network interfaces by applying a network selection criterion to the 
network interface information potentially spanning multiple media ([0053-55] e.g., IfManager 
takes care of interface connectivity, management, and selection being performed by choosing the 
best interface according to context and user preferences) 
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18. As per claim 29, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion is accessed from a configurable rules data store ([0036] 
e.g. NISP) 

19. As per claim 30, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the computer-executable instructions further facilitate issuing network interface 
configuration instructions in accordance with the designating step ([0054], [0070-72] e.g., 
connectivity, management, and selection implies that a selected card is configured accordingly. 
For example, insertion/removal of a card entails a new configuration) 

20. As per claim 32, Melpignano et al. teaches the computer-readable medium of claim 31 
further comprising computer- executable instructions for acquiring, by the media specific 
modules, network interface information from the communication media drivers associated with 
particular network interfaces ([0049-50] e.g., it is understood that interface device drivers 
provide status, capability, and list of reachable access points for a respective interface) 

21 . As per claim 34, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order between at least two media 
based upon a network parameter associated with the media ([0050] e.g., physical characteristics) 

22. As per claim 35, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order between at least two media 
based upon a network type associated with the media([0050] fType) 

23. As per claim 36, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order based upon a current location 
of the computing system ([0052] e.g., location) 
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24. As per claim 37, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order between logical networks 
([0050] e.g. WLAN, WPAN) 

25. As per claim 38, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein the network selection criterion specifies a preference order based upon a network time 
of use parameter ([0051] e.g., 'already been visited') 

26. As per claim 39, Melpignano et al. teaches the computer-readable medium of claim 28 
wherein machine the computer-executable instructions comprises a rules engine for evaluating at 
least one of the network selection criteria based on the accumulated network interface 
information ([0053] e.g., IfManager), and further comprising computer-executable instructions 
for cyclically performing, under the control of a state machine: scanning a set of network 
interfaces for networks ([0057], [FIG 4]); applying, with the rules engine, the network selection 
criterion to a set of networks and interfaces to render a current network and interface selection 
([0054]); and issuing configuration instructions in accordance with the current network and 
interface selection ([0054], [0070-72] e.g., connectivity, management, and selection implies that 
a selected card is configured accordingly. For example, insertion/removal of a card entails a new 
configuration) 

27. As per claim 45, Shi teaches the computing system of claim 1 , wherein the scanning 
engine increases the scanning delay period when the plurality of previous scans indicate there is 
no change in state ([COL 2 lines 1-15], [COL 4 lines 55-60], [COL 4 lines 14-20] e.g., a state 
change is viewed in comparison to the number of LBT channels. One state would be a 
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substantial number of LBT channels necessitating minimizing the scan rate. Another state would 
be an indication that the user is in a cell overlap area requiring a higher scan rate) 

28. As per claim 46, Shi teaches the computing system of claim 1, wherein the scanning 
engine performs a scan when the plurality of previous scans indicate movement of the computing 
system ([COL 1 lines 65-67], [COL 4 lines 35-40]) 

29. As per claim 47, Shi teaches the computing system of claim 46, wherein the scanning 
engine determines the computing system is moving based on at least one of received signal 
strength ([COL 53-65], [COL 6 lines 1-13] e.g., comparison on RSSI values during a handover, 
i.e., movement) , retransmission counts, or frame error rates.) 

30. Claims 15-19, 21-27, and 41-42 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Melpignano et al. (USPN 2006/0084417 Al) in view over Babbar et al. 
(USPN 2004/01 16140 Al) and in view over Shi (USPN 6807163) 

31. As per claim 15, Melpignano et al. teaches a method for selecting a network and interface 
combination, to which a computing system will initiate a connection via the network interface, 
based upon network information spanning multiple communication media, the method 
comprising: 

accessing a network selection criteria acquired from a plurality of sources ([0039], [0049 - 
suitable main classes of NISP], [FIG 3 -elements 200, 202, 210, 214] e.g., plurality of sources, 
not defined, may comprise multiple sources including user preferences, predefined sets or 
personal policies, and/or classes (AccessPoint, Networklnterface, and Context) where each class 
represents a source of information pertinent to selecting an appropriate interface) 
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accumulating network interface information ([0050 - element 202] e.g., plurality of interface 
cards and associated, class information, further including status information) potentially 
spanning multiple communication media ([0033] e.g., data, fax, video, or speech, and/or Wlan, 
bluestooth) , the accumulated network interface information being associated with a set of 
networks (e.g., WLAN, WPAN) and a set of network interfaces ([0033 lines 3-4]), each network 
interface for connecting the computing system to a network in the set of networks (e.g., 
connectivity to server via networks), the accumulating facilitated by a normalization module 
(e.g., supra claim 1) that converts standardized commands it receives from a rules engine into 
media specific commands to a set of media specific modules (e.g., supra claim 1) ; and 

designating, via the rules engine ([0049], [0055]), one of the set of networks and a network 
interface from the set of network interfaces by applying a network selection criterion to the 
network interface information potentially spanning multiple media ([0053-55] e.g., IfManager 
takes care of interface connectivity, management, and selection being performed by choosing the 
best interface according to context and user preferences.) 

However, Melpignano et al. does not teach that network selection criteria is acquired from at 
least one of a group policy service. Babbar et al. teaches a service level agreement ([0009] e.g., 
a group policy is interpreted as an agreement between at least two entities, the agreement 
providing communication rules between the entities. A contract/agreement pertaining to service 
provisioning is a group policy) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to provide a service level agreement as part of the network selection criteria. Babbar 
et al. teaches that mobile users gain access to network services from a terminal. Service level 
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agreements provide enhanced access to services, including cost, reliability, priority, protection 
from unauthorized access, and system throughput. Melpignano et al. teaches that network 
selection may be based upon security, costs, data transfer speed, and cached context information. 
In effect, because service level agreements illustrate additional selection criteria, it would have 
been beneficial to acquire network selection criteria, as provided by the service level agreement, 
as part of selecting an optimal network. 

Melpignano et al. teaches initiating network scanning ([0040], [0057], [FIGure 3-element 
200 (ImScanning Type) for a designated one or more set of network interfaces ([0055-56]) 
based at least in part upon a scanning algorithm ([Figure 3-clcment 200, [0057] ) that adaptively 
changes a scanning frequency ([0057], [0074-75] e.g., scanning frequency is interpreted as how 
often an entity is checked. Here, an access point may be scanned when a poll interval expires or 
it can be awaked after a new access point wireless event). However, Melpignano et al. does not 
disclose adjusting the frequency based on previous scan results. Shi teaches an adaptive rate 
channel scanning method for adaptively changing the scan rate based on data stored in a channel 
table during previous channels scanned by the channel scan process ([COL 4 lines 30-41) Note: 
Shi is also introduced to address the narrow limitations of the applicant's specification regarding 
the scan rate (should applicant further define 'adapting') 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to adaptively change the scan rate based on previous scan results to adapt to changing 
network conditions as a means to save battery power. Melpignano et al. teaches scanning for 
available access points at periodic intervals. Shi teaches changing the scanning rate based on 
previous scan results to conserve battery power. Since adaptively selecting a scan rate as a 
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function of network conditions (as assessed via previous scan results) saves power, it would have 
been obvious to modify Melpignano et al. to adapt the scan rate based on previous scans. 

32. As per claim 16, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion is accessed from a configurable rules data store ([0039] e.g., user preferences 
implies that a user may modify a policy) 

33. As per claim 17, Melpignano et al. teaches the method of claim 15 further comprising 
issuing network interface configuration instructions in accordance with the designating step 
([0039 lines 8-11]) 

34. As per claim 18, Melpignano et al. teaches the method of claim 15 wherein the media 
specific modules (e.g., Bluetooth, Wlan, etc) are each associated with at least one distinct type 
of communication media driver ([0049] e.g., MWAL handles all drivers for each interface. It is 
implied that there is a unique driver per module, i.e., Bluetooth, Wlan, GPRS, etc) 

35. As per claim 19, Melpignano et al. teaches the method of claim 18 further comprising 
acquiring, by the media specific modules (e.g., interfaces), network interface information from 
the communication media drivers associated with particular network interfaces ([0049-50] e.g., it 
is understood that interface device drivers provide status, capability, and list of reachable access 
points for a respective interface) 

36. As per claim 21, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order between at least two media based upon a network 
parameter associated with the media ([0050] fPriority, [0036] - NISP) 
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37. As per claim 22, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order between at least two media based upon a network 
type associated with the media ([0050] fType) 

38. As per claim 23, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order based upon a current location of the computing 
system ([0052] e.g., location) 

39. As per claim 24, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order between logical networks ([0033] e.g., WLAN, 
PWAN], [0050] e.g., fPriority) 

40. As per claim 25, Melpignano et al. teaches the method of claim 15 wherein the network 
selection criterion specifies a preference order based upon a network time of use parameter 
([0051] e.g., 'already visited or not'). 

41. As per claim 26, Melpignano et al. teaches the method of claim 15 wherein the 
designating comprises evaluating in a rules engine at least one of the network selection criteria 
based on the accumulated network interface information ([0053-56]), and the method further 
comprises cyclically performing, under the control of a state machine: scanning a set of network 
interfaces for networks ([0057], [FIG 4]); applying, with the rules engine, the network selection 
criterion to a set of networks and interfaces to render a current network and interface selection 
([0054]); and issuing configuration instructions in accordance with the current network and 
interface selection ([0054], [0070-72] e.g., connectivity, management, and selection implies that 
a selected card is configured accordingly. For example, insertion/removal of a card entails a new 
configuration) 
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42. As per claim 27, Melpignano et al. teaches the method of claim 15 further comprising 
initiating network scanning for a designated one or more of the set of network interfaces based at 
least in part upon a scanning algorithm ([FIG 3-element 200, ScanningType) and previous scan 
results maintained in a scanning history ([0056-57], [0074-76] e.g., lists of AccessPoints, i.e., 
history) 

43. As per claim 41, Melpignano et al, as modified, teaches wherein the rules data store 
maintains network selection criteria from a plurality of sources ([0039-GUI]) and a group policy 
service (e.g., supra discussion on claim 15 pertaining to service level agreements) 

44. As per claim 42, Babbar et al. teaches the computing system of claim 41 wherein the 
sources network selection criteria are acquired from include a provisioning service ([0009- 
Quality of Service provisions relating to the delivery of services and content as part of the 
service level agreement) 

45. As per claim 44, Babbar et al. teaches the method of claim 28 wherein the plurality of 
sources of the network selection criteria are acquired from include a provisioning service ([0009- 
([0009- Quality of Service provisions relating to the delivery of services and content as part of 
the service level agreement) 

46. Claim 48 is rejected under 35 U.S.C. 103(a) as being unpatentable over Melpignano et al. 
(USPN 2006/0084417 Al) in view of Shi (USPN 6807163), and in further view over Hartless et 
al. (USPN 6292660) 

47. As per claim 48, Hartless et al. teaches the computing system of claim 1, wherein the 
scanning engine ([Figure 3-element 14] e.g., Melpignano et al. also teaches a scanning engine, 
which may be modified to include the functionality of element 14, as per Hartless) is configured 
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to detect a network interface to be scanned is sending traffic ([Col 4 lines 4-8], [Col 5 lines 15- 
20] e.g., traffic, i.e., signals, are used to determine motion of the mobile device. It is determined 
that the mobile is sending traffic, i.e., in communication with a site, via analyzing signals. A low 
fade rate would imply that the mobile is not moving but determined to be in communication with 
a site. When it is determined that the mobile is not moving, it is therefore not necessary to scan 
at a particular interval because the mobile is determined to be in communication with a site and 
not moving between sites), the scanning engine analyzes statistics (e.g., a statistic is interpreted 
as a collection of quantitative data, i.e., signal, frequency, velocity, etc ) for the traffic (e.g., 
signals are processed by equation ( 1 ) to provide motion estimate) to determine whether a 
scanning period is to be skipped ([Col 5 lines 4-5] e.g. site scanning is not needed) 

Therefore, at the time the invention was made, it would have been obvious to determine 
that that mobile phone is in communication with a site and not moving to determine whether to 
skip scanning period, i.e., skipping a scan interval. Traffic is analyzed (e.g., analyzing signals, 
which are measured. This measurement(e.g., signal) along with the determined frequency 
provide a collection of quantitative data (e.g., frequency, signal strength, velocity, , i.e., statistics, 
which are used in determining motion). Alternatively, as per Table 1 , multiple scan periods are 
depicted. One period may be skipped in lieu of another based on the aforementioned analysis. 

48. Claim 49 is rejected under 35 U.S.C. 103(a) as being unpatentable over Melpignano et 
al. (USPN 2006/0084417 Al) in view of Shi (USPN 6807163), in view over Hawkins (USPN 
7025209), and in further view over Lemilainen et al. (USPN 6681259) 

49. As per claim 49, Melpignano et al. teaches the computer-readable medium of claim 28, 
further comprising: 
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receiving a notification that a new network interface is available ([0070-72] e.g., hardware 
update. It is obvious that interfaces may be added and removed); and 

However, Melpignano et al. does not teach loading another media specific module (e.g. 
network class information. It is obvious to have one class per network interface, providing a 
plurality of classes. One class corresponds to Bluetooth (e.g., type, status), another class 
corresponds to Wlan (e.g. type, status). Each class equates to a module. When a new interface 
is added, a new module is created, as per Hawkins, see below) corresponding to said new 
network interface,. Hawkins teaches installing a network interface module, i.e., loading a media 
specific module, which would correspond to the new interface hardware, such as Bluetooth, 
where such modules contain code (e.g., drivers) configured to provide network information 
([Col 101 lines 6-14]) 

However, Melpignano et al., as modified (e.g., one class per interface type, where a class is a 
module), does not teach said media specific module (e.g., networkclass) configured to request 
network interface information from a driver for said network interface. Lemilainen et al. 
teaches NIC drivers provide features and state information ([Col 10 lines 1 1-30] e.g., this 
illustrates that drivers provide status information) 

Therefore, at the time the invention was made, one of ordinary skill in the art would have 
motivation to enable the networkinterface class (e.g., module) to request status information using 
network interface drivers. Melpignano et al teaches that interface status is requested - element 
202 (ifStatusFlags). Lemilainen et al. teaches NIC drivers provide status information. 
Therefore, it would have been obvious to use NIC drivers to relay state information to the 
networkinterface module -element 202. As modified, there is a network interface module 
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(element 202) for each type of module (e.g., Bluetooth, GPRS, WLan). As new interface cards 
are added, a new module, as per Hawkins, is added to reflect this addition. 



Conclusion 

7. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to DARRIN DUNN whose telephone number is (571)270-1645. 
The examiner can normally be reached on EST:M-R(8:00-5:00) 9/5/4. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Albert DeCady can be reached on (571) 272-3819. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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Supervisory Patent Examiner 
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